❯❯ 別瞎用！三種不適用場景與兩題判準：成熟 AI SDD 流程的邊界與勸退指南

📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（邊界）

聊了 28 天這套流程的優點，最後還是要講點實話：遇到下面這三種場景，請直接放棄這個做法。

一套方法論成熟與否，不在於它有多萬能，而在於你能不能講清楚它的邊界在哪裡。如果把這套規格驅動流水線（SDD Pipeline）硬套在不合適的情境上，那就只會付出高昂的治理成本，卻拿不到任何品質效益。

場景一：規格頻繁更迭的探索期專案

這套流程的地基是「規格即真理（Single Source of Truth）」，但前提是規格得相對穩定。

如果產品還在早期驗證階段（需求每週變、方向每天修），規格根本算不上合約，充其量只是草稿。這時候若強行導入完整流程，你只會整天被維護流程卡死：改資料流（flow）、調型別定義、解凍 Spec，再補 E2E 測試，時間全花在維護流程異動，根本沒空做真正的產品驗證。

探索期就該用高彈性的 Rapid Prototyping 或 vibe coding（這裡指業界通稱的隨手快寫，不是本系列受紅線約束的 vibe 治理）。等產品方向被市場驗證、規格逐漸收斂，再導入自動化門禁與凍結測試，把穩定下來的區域保護起來。

這一節要與 Day 27 的做法區分開：若只是局部模組的規格難以一次到位，可以用 Vibe 逃生門先寫，事後再補測收編，不必放棄整套流程。但如果是整個產品方向都還在漂，那時連「主流程」都還沒影，根本沒有東西值得你去凍結。

場景二：視覺與互動為核心導向的產品

這套流程的骨架是「邏輯先定、視覺後補」：先把核心業務邏輯（invariant）鎖死，UI 樣式再照著規範填空。

但有些產品（像是品牌官網、互動展演網站、或是滿滿高階 CSS/3D 動效的 Landing Page），賣點全在視覺衝擊與微互動上，行為邏輯反而是附屬品。對這種專案硬套「邏輯優先」的限制，根本是強行打斷設計師與前端試視覺創意的探索空間。

這類專案的自動化測試與檢查，應該放到開發後段再做，千萬別拿規格門禁去卡設計的迭代。

場景三：極簡架構或一次性產品

回顧 Day 27 在晴天娃娃（TeruTeru）專案的經驗：當時實測 OpenSpec 的逐頁確認機制，高頻率的人工確認切碎了小型專案的開發節奏；同樣的道理套回這套流程，完整的門禁與凍結機制對這種小體量的案子來說，完整的門禁與凍結機制實在太重了。流程運作本身就是有成本的，專案規模只要低於臨界值，跑流程的花費就會遠超維護收益。

生命週期短的活動頁、臨時寫來用的內部工具或是概念驗證 prototype，開工直接寫就好；真要講究品質，頂多取流水線前半段（規格 → 測試 → UI）的簡化版出來用。對短命專案套完整工程體系，純粹是浪費資源。

這三種場景不是要把這套流程判死刑，而是提醒大家：動手前先想一下專案特性。只要專案規模與穩定度過了臨界點，隨時再把這套管線掛上來都來得及。

適用性決策矩陣

開工前先想一件事：這專案的核心價值，到底是在業務邏輯還是視覺體驗？如果是後者，直接走場景二（視覺優先，測試後面再補）。如果確認核心價值在行為邏輯，再拿這張表評估：

通過這兩關判斷，導入自動化門禁的投資才真的划得來。這套流程要解決的是長遠的架構秩序，而不是初期圖個爽快的開發速度。

懂一個工具的極限在哪，才算真正掌握它。邊界界定完畢，明天最終章：釋出開源 Repo，聊聊這套流程還能怎麼演進！

📎 本篇證據｜晴天娃娃實測 OpenSpec 的過重體感（D2／D27，PinyiW0/TeruTeru 的 openspec/ 目錄可查）・三個專案的適配對照（D27 表）